Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Total variation #1118

Merged
merged 22 commits into from
Jan 19, 2024
Merged

Total variation #1118

merged 22 commits into from
Jan 19, 2024

Conversation

zstone1
Copy link
Contributor

@zstone1 zstone1 commented Dec 15, 2023

Motivation for this change

Bounded variation stuff to build the lebesgue stieljes charge. The end goal being applying radon nikodym for FTC.
This proves that if f has bounded variation, it can be decomposed into a positive part and negative part. And that those have sane continuity behaviors.

The remaining bit to apply radon nikodym is

Definition lusinN (A : set R) (f: R -> \bar R) := forall E, E <= A -> measurable A -> mu A = 0 -> mu (f @` A) = 0
Definition absolute_continuity a b f := {within [a,b], continuous f} /\ bounded_variation a b f /\ lusinN [a,b] f. 
Lemma lusinN_TV a b f : absolute_continuity a b f -> lusinN (TV a ^~ f).
Lemma absolute_continuity a b f -> mu << "lebesgue_stiljes_charge f" (should be easy corrolary of lusinN_TV)

That'll give us enough to prove FTC. But to make it useful, we'll also need

Lemma differentiable_lusinN : {in (a,b), differentiable f} -> lusinN (a,b) f

which might be best to go through lipschitz, I'm not sure.

Things done/to do
  • added corresponding entries in CHANGELOG_UNRELEASED.md
  • added corresponding documentation in the headers
Compatibility with MathComp 2.0
  • I added the label TODO: HB port to make sure someone ports this PR to
    the hierarchy-builder branch or I already opened an issue or PR (please cross reference).
Automatic note to reviewers

Read this Checklist and put a milestone if possible.

@affeldt-aist affeldt-aist marked this pull request as draft December 21, 2023 05:08
@affeldt-aist
Copy link
Member

Here is a tentative to use path to define partition (that I renamed division because partition is a bit overloaded): https://github.com/affeldt-aist/analysis/blob/total_variation/theories/realfun.v#L680

I haven't yet completely ported the continuity proofs though (and the rest is still dirty but that can give a good idea of the difference).

@affeldt-aist
Copy link
Member

The last commit redefines partition (renamed itv_partition to avoid overloading) using path and reproves the basic theory. The reimplementation is transparent enough so that the last bit of the development (about TV and continuity) is left unchanged.

@zstone1 zstone1 changed the title Draft: Total variation Total variation Jan 8, 2024
@zstone1 zstone1 marked this pull request as ready for review January 8, 2024 00:31
From mathcomp Require Import path.
Require Import sequences.

Notation "'nondecreasing_fun' f" := ({homo f : n m / (n <= m)%R >-> (n <= m)%R})
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

the notation nondecreasing_fun and nonincreasing_fun have been introduced in realfun.v in the meantime


End total_variation.

Lemma at_left_at_rightP
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this lemma is now in normedtype.v and named cvg_at_leftNP

theories/realfun.v Outdated Show resolved Hide resolved
@affeldt-aist
Copy link
Member

(I just made a few comments to mark a few lemmas that made their way into master recently.)

@affeldt-aist
Copy link
Member

(If the itv_partition/bounded_partition/total_variation looks stable enough, we could maybe make a separated PR to merge it asap?)

@zstone1
Copy link
Contributor Author

zstone1 commented Jan 11, 2024

Cleaning up the duplicate lemmas and notations sounds good. Other than the admits, is there anything else required? I can make an attempt on those today/tomorrow.

@zstone1
Copy link
Contributor Author

zstone1 commented Jan 12, 2024

I filled in that last admitted. The statement of the admit was incorrect. That is

 {within `[a,b], continuous f} <-> {in `],a,b[, continuous f} /\ f ^'+a --> f a /\ f^'-b --> f b

is false. It needs a<b. Note that strictness is required, as even when a = b the LHS is trivially true, and the boundary conditions on the RHS are non-trivial. Thankfully a<b was already in scope, so it's simple to fix.

I've been working in Coq for 4 years now, and I'm still regularly caught of guard by how pedantic it is. Every time I try to use admits in my workflow I make a mistake like this. I'm just glad this one didn't involve any major rework.

@affeldt-aist
Copy link
Member

I made a first pass for minor checks.
I could streamline a few proof scripts, fix comments
and naming, do some renaming, remove one or two unused lemmas.
The lemma path_lt_last_filter (my bad) still looks a bit ad hoc
but I couldn't find a generalization right away.
The name total_variation_jordan_decompE does not really
correspond to the elements used in the statement.
What about bounded_variation_neg_tvE?

@zstone1
Copy link
Contributor Author

zstone1 commented Jan 13, 2024

Changed jordan_decompE lemma to be

Lemma bounded_variation_pos_neg_tvE a b f : BV a b f ->
  {in `[a, b], f =1 (fine \o pos_tv a f) \- (fine \o neg_tv a f)}.

which is a little bit more obvious. As far as path_lt_last_filter goes, I agree it doesn't yield an immediate generalization in this context. I'm not sure how to improve it, so I'm fine with it's current state.

@affeldt-aist
Copy link
Member

@IshiguroYoshihro Since you have been playing around with the definitions in this PR, could you take a quick look to see if there is something we can improve?

@affeldt-aist
Copy link
Member

cd4bf11
is just the observation that we can write variation with next and prev from path.v.
This feels natural and I was therefore hoping that it would help reduce the size of the proof of variation_itv_partitionLR
which is the only lemma that uses variationE (variation using zip) but I failed.
The proof is getting much longer because of low-level manipulations of index and nth (that shows up because
of next_nth and prev_nth). Am I using the path library the wrong way?
In any case, aren't variation_next and variation_prev worth keeping around?

@zstone1
Copy link
Contributor Author

zstone1 commented Jan 17, 2024

Oh, nice. A bit sad it doesn't clean up the proof, but it should allow for nicer "term-by-term" comparisons in the future, so you should merge those in regardless.

@affeldt-aist affeldt-aist added this to the 0.7.0 milestone Jan 18, 2024
@affeldt-aist affeldt-aist merged commit 8d49e8e into math-comp:master Jan 19, 2024
12 of 13 checks passed
affeldt-aist added a commit to affeldt-aist/analysis that referenced this pull request Jan 19, 2024
* total variation proofs

- increasing implies BV
- splitting partitions
- right/left continuity of TV
- define variation with path
- adding monotone variation
- variation using prev and next

---------

Co-authored-by: Reynald Affeldt <[email protected]>
proux01 pushed a commit to affeldt-aist/analysis that referenced this pull request Jan 20, 2024
* total variation proofs

- increasing implies BV
- splitting partitions
- right/left continuity of TV
- define variation with path
- adding monotone variation
- variation using prev and next

---------

Co-authored-by: Reynald Affeldt <[email protected]>
proux01 pushed a commit that referenced this pull request Jan 20, 2024
* total variation proofs

- increasing implies BV
- splitting partitions
- right/left continuity of TV
- define variation with path
- adding monotone variation
- variation using prev and next

---------

Co-authored-by: Reynald Affeldt <[email protected]>
@proux01 proux01 added TODO: MC2 port This PR must be ported to mathcomp 2 now that the. Remove this label when the port is done. and removed TODO: MC2 port This PR must be ported to mathcomp 2 now that the. Remove this label when the port is done. labels Jan 20, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants